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(57) ABSTRACT 

Apparatus for re-assembling information cells of messages, 
comprising a message memory, a message data memory, a 
location memory, and loading apparatus. The message 
memory stores each message in blocks that can be different 
lengths. The message data memory stores, for each message, 
message data defining a location in message memory, a 
position in the block, and a length of the block that is to 
receive the cells of the message. The location memory 
stores, for each message, an indication of the location of the 
message data. The loading apparatus receives the cells, and 
for each cell, accesses location memory to determine the 
location of message data, stores the cell in the message 
memory at the indicated location, increments the message 
data defining the location and the position, and compares the 
incremented position with the stored length of the block to 
determine whether the end of the block has been reached. 

9 Claims, 13 Drawing Sheets 
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DATA TRANSFER 



FIELD OF THE INVENTION 

The present invention relates to the transfer of data, for 
example the transmission of multiple data messages over a 
single transmission medium and the conversion of those 
messages into a form suitable for transmission, 

BACKGROUND OF THE INVENTION 



10 



There is a growing market in the field of digital commu- 
nication. An increasing number of households have equip- 
ment to receive digital television, satellite and cable 
television, telephony and internet services. Telephony sys- 15 
terns and the internet are interactive systems over which 
people can send and receive information and other digital 
communication systems are increasingly tending towards 
interactivity, for example as video-on-demand systems are 
introduced. 20 

Video, audio and other information (e.g. internet 
services), all hereinafter referred to as "data", can be trans- 
mitted along a number of transmission media, for example 
over electrical or optical cable or via radio. The data can be 
considered to be made up of "messages", each message 25 
being, for example, one television channel or one internet 
connection. To allow a plurality of messages to be sent over 
a single transmission channel one approach is to split the 
messages into parts at the transmission device, transmit each 
part over the transmission channel and then recombine the 30 
parts at the receiving device to reconstitute the message. 
Each message is thus contained in a number of parts, which 
can arrive at the receiving device over a period of time. 
Additional information can be transmitted with each 
segment, for example to indicate the message of which the 35 
segment forms part. Consecutively sent messages need not 
then form part of the same message since the receiving 
device can use the additional information to allow it to 
recombine segments of each message with each other. 

40 

One system that uses this principle is AAL5. In this 
system data is transmitted in the form of asynchronous 
transfer mode (ATM) "cells" of 53 bytes in length, of which 
the first 5 bytes constitute the additional information men- 
tioned above and the other 48 bytes constitute the segment 
of the message. By convention each byte consists of 8 bits. 

The messages themselves may be split into higher-level 
parts before they reach the transmission stage: for example 
video data can be in the form of MPEG frames. 

One practical embodiment of a personal system for nan- 50 
dling data in this form is a set-top box. This usually receives 
a digital data feed, forms the received data into digital 
messages, performs the necessary digital-to-analogue con- 
version and final backend processing of the messages and 
outputs signals suitable for use by other apparatus such as 55 
televisions, telephones or internet terminals. There is also 
normally provision for transmission of information 
(normally at a lower data rate) in the opposite direction to 
allow a user to operate interactive services. The reverse data 
can conveniently, although not necessarily be sent in the $0 
same format as the forward data. 

In order to meet the demands of consumers for high data 
rate services such as video a set-top box should preferably 
be capable of receiving and transmitting at a rate of at least 
1 to 10 Mbits/s and preferably of receiving at least 50 65 
Mbits/s. This imposes very heavy demands on the process- 
ing systems that are to perform the transmitting and receiv- 



45 



ing operations, especially the segmentation of messages into 
parts and the reassembly of those parts. Since the set-top box 
is intended as a consumer product there is a particular need 
to provide a device for performing the transmitting and 
receiving operations that is as inexpensive as possible. 

There are known integrated circuit systems that can 
perform the segmentation and re-assembly ("SAR") func- 
tions described above for use in a personal system. Current 
systems fall generally into two categories, having the fol- 
lowing characteristics: 
Hardware-based Designs 

Very fast dedicated SAR engines (typically 155/622 
Mbits/s) 

Large silicon areas 

Expensive, and although they are hardware-based systems 
they often still require a microprocessor for control 
purposes 

Complicated control registers and memory management 
data structures defined in hardware 

Inflexible, which makes it difficult to adapt them to 
rapidly evolving new standards and markets 
Software/Processor-based Designs 

Relatively slow (usually sub 20 Mbits/s) 

Can be inexpensive with cheap RISC (reduced instruction 
set computing) processors, but become uneconomic in 
embedded situations at high data rates (40-50 Mbits/s 
upwards) because expensive high performance proces- 
sors are needed 

Flexible, as all control and data structures are software - 
defined, so easier to modify as standards evolve 

In fact, there are four conflicting design requirements 
which need to be met for widespread consumer use: 

Cost Targets. To a large extent the cost of an integrated 
circuit SAR engine is determined by the complexity of 
the circuit and the die area it occupies. Known 
hardware -based systems generally occupy large areas 
and whilst low-cost RISC software-based systems are 
cheaper to produce, their performance is modest. 

Flexibility to meet evolving standards. Hardware -based 
systems are generally inflexible. 

Performance targets. Existing hardware-based solutions 
have high performance but are too expensive for many 
consumer applications. Existing software-based solu- 
tions are cheaper but have modest performance. 

Ease of Interfacing to other parts of the system. 

It is clear from the above analysis that the SAR engines 
currently available do not provide an effective technical and 
cost-effective solution. 

SUMMARY OF THE INVENTION 

According to a first aspect of the present invention there 
is provided an apparatus for re- assembling information cells, 
each comprising a respective part of one of a plurality of 
messages and cell content information indicating the identity 
of the message a part of which is carried, comprising 
a message memory for storing the plurality of messages, 
each in one or more blocks, the blocks for the respec- 
tive data streams being capable of being of different 
lengths; 

a message data memory for storing, for each message, 
message data defining a location in the message 
memory, a position in the respective block and the 
length of one of the blocks that is to receive cells of the 
message; 
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a location memory for storing, for each message, an DESCRIPTION OF THE PREFERRED 

indication of the location of the message data stored for EMBODIMENTS 

that message in the message data memory; Basic s tem 

loading apparatus for receiving the cells and for each cell „„, , . „ , .. . , . 

accessing the location memory to determine the loca- s FIG> . 1 shoW 5 an derail schematic view of a system for 

tion of the message data for the message apart of which transmitting and receiving data according to an embodiment 

is carried by the cell, storing the cell in the message ° f *? present mention. The svstem comprises a network 

memory at the location indicated in the message data, e ™±^™ at 1 ? 0 ' a termmal . end *°™&? a *! t l 

incrementing the message data defining said location at ™ and a bidirectional communications link 300 (which 

and said position for the block in the message data 10 ^ f ° r «! m P Ie be P™ ldeA by a telephone network, a 

memory by an amount equal to the length of the part of dedicated cable connection or a radio link) between the two 

the message carried in the cell and comparing the ends - Inc ° mm g vlde ° ™d other data streams 101, 102 are 

incremented position with the stored length of a block segmented at the network end and transmitted along the link 

for the message to determine whether the end of the 300 88 ^ ° elW ""f* 001,8 each contain a P art of a 

block has been reached 15 messa 8 e and have cell content mformation prepended to 

As each part of a message is received, the loading ' * em - ™» f. 11 u content ^formation indicates ; (among other 

apparatus preferably performs an error check calculation on mm 8 s ) of J"*"* mes f a 8 e th A ce11 forms P art - ™™ the 

the segment and stores the result for the respective message arnv6 at me tcrmmal 6nd 200 ' whlch m ^ example * a 

in the message data memory. personal system 11, they are re-assembled in the SAR engine 

On receiving in a cell error check information for a 20 3 and sent to an STB data processing unit 201. This converts 

message, the loading apparatus preferably compares that me me f a 8 es ml ° a f ° m suitable for ^'P* 10 °*«*.«F9- 

error check information with the stored error check infor- me f for D e A x J™P l6 \ b 7 ^erUng MPEG frames into an 

mat j on analogue PAL television feed. From the STB unit 201 the 

The location memory is suitably a content addressable messages are sent to the appropriate output device. Data 

memory. The apparatus is preferably provided on a single 25 &om » controller or&om a personal computer, for example, 

integrated circuit. Preferably the integrated circuit comprises I s rcccived at me S ™ ^it, which converts the received data 

a Central Processing Unit (CPU). At least part of the into a message m a digital form suitable for input to the SAR 

message data memory is preferably provided separately en S me 3 ' ^ SA ? en 8 me . th 5 n ta ? k » ,ms messa 8 e mto 

from the integrated circuit. segments, adds cell content mformation to each segment to 

The cells are preferably ATM cells. The length of the part 30 form 311 .A™ c f U and ,hen transmits the cells over the 

of the message carried in each cell is suitably 384 bits. communications link 300. The two ends also exchange link 

According to a second aspect of the present invention contro L 1 mformaUon for example to negotiate the data rate 

there is provided a method for receiving a plurality of data ]mk > m *? * m of *™ ^ 11 wlU be appreciated 

streams over a data channel, the method comprising per- mat ' he ™? ° J fan STB umt 15 merel y an exam ? le a efordmg 

forming the steps set out above in relation to the first aspect 3 S * thlS 6mbod,mcnt > one P osslble alternative is an internet 

of the invention. ada P ter card ' 

The present invention will now be described by way of In m e personal system each message or data stream is 

example with reference to the accompanying drawings in considered to constitute a virtual channel (VC). 

which: The SAR engine is provided on a single integrated circuit, 

BRIEF DESCRIPTION OF THE DRAWINGS « to ^ b V "^including J"*"?* a ° d a CPU. The 

111 general architecture of the integrated circuit, according to 

FIG. 1 shows a simple schematic diagram of the functions one embodiment of the present invention, is shown struc- 

performed over the network system and at the user end turally in FIG. 2, and more functionally (together with links 

according to an embodiment of the present invention to off-chip RAM, the ATM physical interface and MPEG 

FIG. 2 shows the general architecture of the SAR engine 45 transport back end) in FIG. 3. 

integrated circuit according to an embodiment of the present Overview of the Function of the SAR Engine 

invention yj ie engine performs the following basic functions: 

FIG. 3 shows the function of the SAR engine integrated 

circuit of FIG 2 Segmentation of outgoing ATM VCs from memory 

FIG. 4 represents the interfaces to the present SAR engine 50 Reassembly of incoming ATM VCs into memory 

FIG. 5 shows the reassembly architecture and data flow The memory that is used for these functions could be on or 

FIG. 6 shows a detail of the Context Memory system used off tne chi P on wnich tne SAR en gi ne is provided, or both 

during reassembly types of memory could be used together — for instance some 

FIG. 7 shows the reassembly buffer organisation messages could be held in on-chip and some in off-chip 

FIG. 8 shows the structure of the buffer memory in 55 mem0r> ; B u ecause ° L f the hi S h data rate , s [for video it is 

hardware preferred that on-chip memory is used for video VCs. 

FIG. 9 shows a linked-list for data to be transmitted ^ local environment of the SAR engine of an embodi- 

F1G. 10 shows a free-list for data to be transmitted mc * X of thc J rcscni invention » shown * FIG. 4, including 

FIG. 11 indicates a possible structure of the buffer , n ^y ^rfacesan^ 

memory in software 60 P art f th f P crs ° nal *£ te " * * FIG. 1. The 

or/-, i^u .1. arrival and departure of the ATM cells can be represented by 

HQ. 12 shows the segmentation data structure thc ATM ?hy ^ Layef L , n ^ cmbo dwcnt, the rate of 

13 shows the segmentation architecture and data data arrival is 40 Mbits/s and the system is able to deal with 

32 channels at a time (i.e. 32 messages) in each direction. 

FIG. 14 illustrates the structure of the content addressable 65 Tne"cells\are' interfaced with the SAR engine 3 via a 

memory. UTOPIA port 2 which implements a standard UTOPIA 

In the figures like reference numerals indicate like parts. interface. At the other side of the SAR engine, there is a bus 
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system 4 which allows transfer of data to the appropriate 
external memory 5. Two forms of external memory can be 
provided, namely shared RAM 5a, which is shared with 
other control functions in the STB, and optional RAM Sb. 
Shared RAM 5a can be used as a buffer for control infor- 
mation and signalling (channel) data, and it can be accessed 
by the SAR engine via a Programmable Processor Interface 
(PPI) 4a. The optional RAM 56, is accessed by the SAR 
engine via an external bus interface 4b, and can be used in 
configurations where additional memory is needed, for 
example in environments where a high level of jitter is 
experienced. The SAR engine places MPEG frames in 
memory, from where they are fed via a dedicated MPEG 
video output 4c to an MPEG transport layer device 4d. 

All or part of the external memories could be provided on 
the integrated circuit of the SAR engine. 

The SAR engine implements encoding and decoding of 
dataaccording to the AAL5 standard. The implementation of 
the AAL5 function for both MPEG2 frames and signalling 
and control frames is split, with CPCS/SSCS functions for 
^signalling/control frames performed in software and func- 
tions for MPEG2 frames in hardware. 

The functions of the SAR engine will now be described in 
more detail. 

ATM Cell Reception and AAL5 SAR-PDU Reassembly 

FTG. 5 shows the on-chip architecture of the SAR engine 
in more detail. 

Incoming data is received from the ATM physical layer 1 
at port 1. The UTOPIA port 2 performs an error check on 
four bytes of the ATM cell header by calculating a check, 
such as a CRC, and comparing that with the HEC (header 
error check) word in the fifth byte. The UTOPIA port can be 
configured by the CPU to either reject or pass through cells 
whose headers contain an error. 

The "front-end" hardware of the reassembly function 
comprises one or more state machines, namely a control 
logic unit 6, a cyclic redundancy check (CRC) unit 7 for 
implementing the AAL5 CRC processing, a content addres- 
sable memory (CAM) 8 and a DMA engine 9, These 
functions are shown logically in FIG. 5, but it should be 
understood that this does not necessarily correspond with the 
physical structure. 

An on-chip context memory 10 is provided as an SRAM 
and is used to store context information for the incoming 
data stream. The context information is made up of a set of 
data for each message channel that is to be received, 
indicating information that is to be used in reassembling the 
ATM cells. If a cell is received with header information 
which does not correspond to stored context information, a 
signal can be sent to the processor 12 to allow the processor 
to handle the cell itself, or the cell can be discarded, 
depending on the configuration of the device. It will be 
appreciated by those skilled in the art that the context 
memory 10 could alternatively be provided off-chip. 

A processor 12, which in this case is an ST20-C2 
processor, can control and receive information from the 
UTOPIA port 2, the control logic 6, the CRC engine 7 and 
the DMA engine 9 by means of respective control paths. The 
processor 12, the DMA engine 9, the CAM 8 and the context 
memory 10 are linked to each other and to external bus 
interfaces 30, 31 by an internal data bus 32. External local 
bus interface 30 provides an interface to off-chip memory 
Sb. External shared bus interface 31 provides an interface to 
off-chip memory 5a shared, for example, with an optional 
external control CPU. 

In operation the CAM 8 and the context memory 10 are 
set up under the control of the processor 12, using the 
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internal bus 32, to hold information needed to reassemble 
each message channel that is to be received. The processor 
allocates a block of memory in the context memory 10 to 
hold context information for use in reassembling cells of that 
message. The processor also allocates storage buffer 
memory, either in the memory 10 or in another memory (for 
example off-chip memory) to receive the incoming data. In 
the allocated block in the context memory the following 
information, which is illustrated at 40 in FIG. 6, is held: 

a 32-bit pointer to the position in the storage memory 
where incoming data is to be stored; 

a value for a running CRC; 
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30 



35 



40 



45 



55 
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a 16-bit maximum length of the PDU (protocol data unit) 
that is to be received; 

a 16-bit current length of the PDU indicating how much 
of the PDU has so far been received. 
Other numbers of bits could be allocated to each field, 
depending on the implementation. The processor stores 
initial values for each of these fields into the allocated block 
in the context memory, 

32 sections are available in the context memory 10, each 
corresponding to one of the 32 receive channels that can be 
handled in hardware. Therefore, in the present embodiment 
32 incoming channels can be processed by the basic reas- 
sembly mechanism without the need for extra processor 
support. By extending or re-using the context memory with 
additional support from the processor, more channels can be 
processed. The system also provides exception mechanisms 
for handling these further channels that are described in 
more detail below. 

The ATM header information (including the VQ/VPI for 
the cell) is extracted by the control logic 6 and applied to the 
CAM over an internal bus 33. The bits of the header that are 
not relevant to the CAM are masked out under the control of 
initialisation software. The CAM is a 64 bitx32 entry CAM. 
The CAM indicates whether the cell header matches any of 
the cell headers in the CAM by returning the number of the 
entry in the CAM where the match occurs. The blocks in the 
context memory begin at evenly spaced memory addresses 
so by multiplying the returned entry by the spacing and 
adding an offset the control unit returns the start address of 
the appropriate block in the context memory 10. Alternative 
ways of deriving the start address — such as look-up tables — 
could be used instead. 

If there is no match for the VPI/VCI in the CAM then 
depending on the configuration of the device one of the 
following four methods may be used: 

1. The cell is simply discarded. 

2. A signal is sent to the processor 12 (e.g. by means of 
an interrupt) to indicate that there is no match for the 
current cell. The signal itself could give the identity of 
the message from which the cell comes, or the proces- 
sor could access the cell directly to determine that. The 
processor then decides whether the cell is one that is 
desired to be received. If it is then the processor 
determines a block in the memory where that message 
can be or is being stored, configures a block in the 
context memory if one does not already exist for the 
message and an entry in the CAM accordingly and then 
signals the SAR unit to repeat its attempt to process the 
cell as normal. In the meantime the SAR engine could 
have been suspended waiting for the signal from the 
processor or could have been processing other cells, 
with the unmatched cell held in a reserve buffer. If the 
processor determines that the unmatched cell is not 
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wanted then it could signal the SAR engine to discard control logic 6 accesses the context memory at an address 

the cell. This method allows the processor to configure offset by 64 bits from the start address to obtain the pointer 

the SAR unit to perform efficient hardware-based stored there. The pointer indicates the memory location in a 

reception of a data stream that is expected to be ram 5 where the data is to be stored. The control logic 6 

received frequently. 5 wri les this pointer to the DMA engine 9, and checks the 

3. A signal is sent to the processor (e.g. by means of an memory location. The DMA engine then stores the 48 bytes 
interrupt) to indicate that there is no match for the 0 f data from the cell at that location. 

current cell. The signal itself could give the identity of 0 nce the DMA engine 9 has stored the data, the control 

the message from which the cell comes, or the proces- x ic 6 increments by 48 bytes the inter in tne context 

^n™^ h W y k T 1De tha ,!; 10 identified b y ^ start address. Tins allows the next piece of 

processor then decides whether the cell is one that is ~ * v * j • *i_ 

desired to be received. If it is then the processor d ^ ° f * e . ^ ™ SSa § e * , be 5{ ™ d in the mm f 

determines a block in the memory where that message ^sequent locaUon. The control logic 6 also increments the 

can be -or is being stored, configures a block in the in the context identified by the start address by 48 

context memory if one does not already exist for the for ^ in memor y management as described below, 

message and then applies to the SAR unit the informa- 15 l \ ^ be appreciated by those skilled in the art that by 

tion that would be expected to be received directly or simple changes to the system, other cell sizes could be 

indirectly from the CAM to indicate that that context is processed, and the incrementing of the pointer and length 

to be used (e.g. an entry number other than an integer information altered accordingly. 

from 1 to 32, or the start address of the context to be The address range into which the pointer falls determines 

used), which signals the SAR unit to repeat its attempt 20 whether the cell is written into the internal SRAM or the 

to process the cell as normal. In the meantime the SAR external RAM, as illustrated in FIG. 7. In this embodiment, 

engine could have been suspended waiting for the typically video information is stored in an on-chip memory 

signal from the processor or could have been process- Sa and other data is stored in an off-chip memory 5b. The 

ing other cells, with the unmatched cell held in a device can be configured to support other storage arrange- 

reserve buffer. If the processor determines that the 2 5 ments. In this figure, the data stored in one area of a RAM 

unmatched cell is not wanted then it could signal the (for one message) is indicated as 15. At this point in time, the 

SAR engine to discard the cell. This method allows the amount of the particular message which is stored is indicated 

processor to control the SAR unit to make efficient use by the shaded area sized as "length" 16 and the maximum 

of more contexts than can be supported by the 32 available space ("maximum length") is indicated as 64 kbyte 

entries in the CAM. 30 17. 

4. The SAR unit accesses a register (e.g. in the internal The last cell in the PDU is indicated as such by informa- 
RAM) that gives the location of a buffer for unmatched tion in its ATM header. If the system is configured to do so, 
cells. The cell is stored at that location together pref- reception of this cell triggers the special action of checking 
erably with its header information (or other data) to the CRC stored in the context memory for the entire message 
indicate the message from which the cell comes. The 35 against the CRC transmitted in the last cell. If the two do not 
register is then incremented to give the address of the match then the CRC fails and an error is signalled to the 
next location in the buffer to receive unmatched data. CPU 12; otherwise a 'PDU complete' indication is signalled 
The processor can then, in parallel with the subsequent to the CPU, if this function is enabled. 

operations or the SAR unit, process the contents of that Jitter Handling 

buffer to reassemble messages or discard cells from the 40 In normal use the ATM cells can be expected to arrive 

buffer in software. The processor could be signalled by irregularly, at variable time intervals. Once the cells have 

the SAR unit or by other means when the buffer is half been combined, for example into MPEG frames, it may be 

or more nearly full (e.g. by comparing the location desirable for them to be sent out of the apparatus at more 

stored in the register with a the value of a trigger regular intervals. If, for example, they are MPEG frames 

location stored in another register) or the processor 45 carrying video information, time delays (jitter) between 

could itself periodically check on the buffer. When the them in the middle of a message would produce a problem 

processor has taken the data from the buffer it can reset when actually viewing the channel. Therefore, the SAR 

the location register to allow the buffer to be refilled. engine includes jitter handling software which can be 

This method allows the unit to support processing of enabled for passing the cells at more regular intervals to the 

unmatched cells with very little interruption and con- 50 reassembly apparatus or for passing assembled frames of 

sequent slowing of normal operation. The buffer for cells at more regular intervals to downstream equipment 

unmatched cells could be just one cell in size or larger, such as video decoders. The cells/frames are received and 

for example 20 cells or more in size. If the buffer were stored in a buffer memory, which may be as already 

one cell in size then the SAR unit should preferably described. A signal is sent to the CPU indicating which 

signal the CPU immediately, for example by means of 55 cells/frames are stored, and the CPU executes instructions to 

an interrupt, when a cell was placed in the buffer to determine the time at which the next cell/frame needs to be 

allow the processor to handle the cell promptly. transferred. At that time it informs access software of the 

In any of the cases the SAR unit can (depending on location in the buffer memory from which to take the next 

configuration) signal a no-match exception to the CPU. cell/frame, and the access software can then retrieve the 

Methods 2, 3 and 4 provide useful ways of extending the 60 cell/frame and transmit it to downstream apparatus. In this 

capabilities of the system beyond the limitations of the size way, real-time delays or irregularities in the relevant stream 

of the CAM, which can allow the system to combine the of data are prevented, minimised or at least reduced. An 

benefits of quick dedicated processing of cells with the advantage of this particular invention is that this process is 

benefits of flexible software-based processing and without all done in software. This allows fully flexible control over 

calling for a larger and more expensive hardware CAM. 65 the de-jittering operation and particularly in combination 

If there is a match in the CAM then the 48 data bytes of with fast hardware-based reassembly of the received cells 

the received ATM cell are applied to the control logic 6. The can substantially minimise jitter and allow only a relatively 
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small buffer (which may already be used for reassembly) to 
be needed for de-jittering. 
Memory Management 

For ease of management of the memory system, a 
software-based memory management scheme is supported. 
This gives a substantial advantage over prior art systems in 
terms of flexibility and cost. In certain cases, the PDU 
segmentation and reassembly buffers may be made deliber- 
ately smaller than the maximum PDU length (64 k bytes for 
the AAL5 protocol being used) in order to optimise use of 
memory. For example, to support 32 VCs in each direction 
with a 64 kbyte buffer length for each PDU would require 4 
Mbytes of memory. Most of this is likely to be unused at any 
time since typically much of the AAL5 traffic is likely to be 
with much shorter frames than this. In low cost STB 
applications this is an unacceptable cost overhead, so a more 
intelligent use of buffer memory is required. 

This situation is more likely to occur for the signalling 
PDUs being delivered to the external control processor, 
which could be of any length (up to the maximum 64 k 
bytes) and which will be segmented or reassembled to/from 
the (relatively expensive) shared memory space. It should 
not normally be expected to occur for MPEG2 frames 
because of the small, fixed size of the buffers needed (e.g. 
2x188 bytes). 

The SAR engine hardware therefore provides certain 
support functions to the CPU to enable a number of different 
memory management schemes to be implemented in soft- 
ware. FIG. 8 illustrates the structure of the memory in 
hardware where the received data and data to be transmitted 
is stored. It comprises a reassembly buffer area and a 
segmentation buffer area, each of which is divided into a 
number of buffer blocks for storing PDUs from a particular 
message. The buffer block allocation is performed in 
software, which provides the advantage that the hardware 
can be kept simple, because it simply has to signal to the 
CPU when it runs out of buffer but does not have to perform 
the allocation itself. 

The processor 12 can assign blocks of buffer memory, as 
described above, to each message channel that is to be 
received. The buffer for each PDU is composed of a series 
of "buffer blocks": for example, a set of buffer blocks may 
be approximately 1 kB each in size, so around 64 of these 
would be required to buffer a maximum length AAL5 PDU. 
The buffer blocks are preferably an integer multiple of 48 
bytes in length to accommodate an integer number of ATM 
cells' data exactly during normal operation, easing SAR 
engine implementation. If the blocks are intended to hold 
full received cells then a size that is a multiple of 52 bytes 
is preferred. The buffer blocks may be of different sizes 
assigned by the processor, for example on the basis of the 
type of service that is to be received over the message 
channel. The blocks can be chained via a linked list (or other 
mechanism). Such a linked list for data to be transmitted is 
illustrated in FIG. 9. This shows the queue of data, each 
PDU having first and last block pointers. These pointers are 
used by the CPU to allocate the buffer blocks in the most 
efficient way. The "back" pointer is optional, because a 
similar function can be performed in software using "last 
block" header information. An advantage of this system is 
that the allocation functions are performed in software, 
which means the hardware is kept simple as explained above 
with reference to FIG. 8. Buffer allocation for incoming data 
is performed similarly. 

A "free-list" of unassigned buffer blocks is maintained by 
the processor 12, each of which may be chained to any of the 
PDU buffers to extend its size when a buffer overflow 
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occurs. This is shown in FIG. 10 for cells to be transmitted; 
a similar structure is provided for incoming data. 

FIG. 11 shows how the buffer for cell transmission could 
look in practice. It shows how multiple message queues are 
5 allocated to a buffer memory in which the linked-list and 
free-list buffer blocks are interleaved. A similar structure 
could be used for incoming data. 

When a message channel is first to be received the 
processor allocates a first buffer block to that channel, stores 

10 the length of that block in the maximum length field of the 
appropriate context block and stores a pointer to the base of 
the block in the context memory. As each cell of the message 
is received the current length field of the block is incre- 
mented as described above and the incremented length field 

as is compared with the maximum length field to determine 
whether the end of the buffer block has been reached. If the 
end of the block has been reached without the last cell of the 
PDU having been received, i.e. the incoming PDU exceeds 
the current PDU buffer, the SAR engine generates an "over- 

20 flow" interrupt to the CPU 12. In response the CPU 12 
allocates another buffer from the free-list to the message and 
alters the pointer, length and if necessary the maximum 
length fields in the appropriate context block to reflect the 
new buffer block. 

25 When a complete PDU has been received the unit that is 
to receive the reassembled message can retrieve the message 
from memory. Once the message has been retrieved the 
processor restores the block of memory to its list of free 
blocks that can be allocated. 

30 Segmentation 

In this embodiment the memory from which data is taken 
is the off-chip RAM Sa s but the operation is equally appli- 
cable to an on-chip memory. This off-chip RAM 5a contains 
a number of messages to be transmitted. The segmentation 

35 operation is essentially the reverse of reassembly, except that 
an ATM header needs to be added to each data cell. The 
other difference is that support is provided for pacing of the 
outgoing ATM cells in order to send them at substantially 
regular time intervals — this will be described in more detail 

40 below. 

FIG. 12 shows the on-chip segmentation architecture of 
the SAR engine. The "back-end" hardware of the segmen- 
tation function comprises a pacing engine 18, a DMA engine 
9 and a segmentation control engine 44. 

45 An on-chip context memory 10 is provided as an SRAM 
and is used to store context information for the outgoing data 
stream. The context information is made up of a set of data 
for each message channel that is to be transmitted, indicating 
information that is to be used in segmenting the messages. 

50 As an alternative, the context memory could be off-chip, or 
it could be a different type of memory such as a DRAM. 

The processor 12, the DMA engine 9 and the pacing 
engine 18 are linked to each other and to external bus 
interfaces 30,31 by an internal data bus 32. Bus interface 30 

55 provides an interface to off-chip memory 5a, which could 
take various forms such as an SRAM or a DRAM. 

In operation the context memory 10 is set up under the 
control of the processor 12, using the internal bus 32, to hold 
information needed to segment each message channel that is 

60 to be transmitted. The processor allocates a block of memory 
in the context memory 10 to hold context information for use 
in segmenting cells of that message. The processor also 
allocates storage buffer memory, either in the memory 10 or 
in another memory (for example off-chip memory) to trans- 

65 mit the outgoing data. In the allocated block in the context 
memory 10 the following information, which is illustrated at 
50 in FIG. 13, is held: 
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a current running CRC 
some flags 

a pointer to the current position in the PDU 

a current and maximum length for the PDU $ 

VPI/VCI header information 

a next transmission time 

a transmission interval 

The pointer and PDU lengths aid buffer management, and 
the transmission time and interval are used by the pacing 10 
engine for the scheduling of ATM cell transmission to the 
physical layer (described below). 

The processor stores initial values for each of these into 
the allocated block in the context memory. 

Within the segmentation engine there are a number of 15 
registers which control or indicate the status of various 
functions, which are described in more detail below. One of 
these is the Current Segmentation register. This is written to 
by the pacing engine and can be read by the CPU, and 
indicates the context that is currently being used by the 20 
pacing engine, i.e. the message currently being sent. The 
segmentation engine takes a portion of data (48 bytes in size) 
from the RAM 5a, and VPI/VCI identification and other cell 
header information is prepended to it, thereby forming an 
ATM cell of 53 bytes in length. This cell is then read by the 25 
DMA engine and transmitted by the segmentation engine via 
the UTOPIA port. 

Once the DMA engine has transmitted the data it incre- 
ments the pointer in the context identified by the start 
address by 48 bytes and updates the CRC. This allows the 30 
next piece of data of the same message to be taken from the 
correct location. The DMA engine also increments the 
length in the context identified by the start address by 48 
bytes. Of course, if a different protocol were being used, 
other cell sizes could be processed, and the incrementing of 35 
the pointer and length information altered accordingly. 

An analogous memory management protocol is used for 
segmentation to that used for reassembly. In the segmenta- 
tion memory management protocol the CPU receives an 
indication of data such as a file that is to be transmitted. This 40 
could be stored in memory on or off chip. The CPU then 
allocates one or more buffers preferably in on-chip memory 
for use in transmitting the file. The CPU loads the first data 
from the file into the first buffer and subsequent data into any 
subsequent buffers. Then the CPU sets up a context with the 45 
details (including the address and size) of the first buffer 
from which transmission of the file is to be performed, and 
causes the segmentation to begin transmission. The segmen- 
tation engine then transmits cells of data from that buffer 
one-by-one as specified by the context. When the buffer is 50 
exhausted (i.e. when the pointer to the next data to be 
transmitted reaches the address of the end of the buffer) the 
segmentation engine checks whether a flag in the context is 
set to indicate that the end of the file has been reached. If it 
has not then the segmentation engine transmits a signal to 55 
the CPU to inform it that the buffer is exhausted. If there is 
another buffer of data from the file ready to send then the 
CPU configures the context to specify that buffer to allow 
the segmentation engine to resume transmission. If there is 
no buffer of data ready to send then the CPU stores the next 60 
data from the file in a new or a different buffer and then 
configures the context to specify that buffer to allow the 
segmentation engine to resume transmission. If the buffer 
specified by the context is the final buffer of data for a file 
then the CPU sets the flag in the context to indicate that the 65 
end of the file has been reached. By keeping at least two 
buffers allocated to the file the CPU can avoid delaying 
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transmission whilst the segmentation engine waits for it to 
transfer data to a buffer. (The segmentation engine could, 
however, send data from other files in the meantime). As for 
reassembly, the CPU maintains a list of free buffers or buffer 
space to allow it to allocate buffers efficiently. As for 
reassembly one aim of the memory management protocol is 
to substantially minimise or at least reduce memory usage. 
This is achieved by the flexible buffering system, including 
the ability to have buffers or pools of buffers of different 
sizes that can be allocated depending on the size or transmit 
rate of a file to be transmitted. The "file" could be any 
suitable data structure. 
Pacing Engine 

The pacing engine, if enabled, acts to select a message 
channel that is to supply the next data to be transmitted. It 
does this by using the "next time" and "valid bit" fields 
stored in the context memory blocks for active outgoing 
message channels (for an explanation of the fields, see 
below). 

The "next time" fields indicate the next time (in relation 
to a clock maintained by the pacing engine) at which it is 
intended that data should be transmitted from the respective 
message channel. The interval fields indicate the intended 
inter-cell interval with respect to the pacing engine clock 
between successive transmissions from the respective mes- 
sage channel. The interval therefore determines the effective 
bit-rate for the message channel. Preferably no interval 
should be less than a cell time, Also the sum of the bit-rates 
for all active message channels should not exceed the 
bandwidth of the port. If the number of active message 
channels n, the interval for the ith message channel is I, and 
T c is the cell time, then this constraint can be written: 

P' yls r c 

Software executed by the processor 12 is responsible for 
ensuring that the sum of the interval values is not less than 
the number of active message channels multiplied by one 
cell time. 

The pacing engine maintains a "current time" clock. At 
programmable time intervals, for example every 10 //s, it 
scans all the context memory blocks for outgoing message 
channels to identify the context whose "next time" field 
indicates the earliest time at or before the "current time", i.e. 
the one which is most overdue for transmission. If none of 
the stored "next times" is at or before the current time then 
an idle cell may or may not be sent. Otherwise the pacing 
engine selects for transmission the message channel whose 
context has the earliest "next time". It should be noted that 
the physical layer at the external side of the UTOPIA port 
can be set up to send idle cells, in which case an idle cell 
transmission would not need to be initiated by the pacing 
engine. 

Each time a non-idle cell is sent, the "next time" field of 
the context memory block corresponding to the message 
channel from which the message was sent is incremented by 
the "interval" value stored in that block. The pacing engine 
also determines whether at that time the length stored in that 
block equals the stored maximum length, and the "last 
block" flag in the flags for that block is not set — this would 
indicate that the processor must now update the context 
memory to refer to a new block of memory so that more data 
can be sent. To signal this to the processor the pacing engine 
sets the "next time" field to an invalid value and signals an 
interrupt to the CPU 12. The memory management system 
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implemented by the processor is then responsible for pro- 
viding the next block of data and setting the "max length", 
"next time" and "pointer" fields and any flags required. 
When the last block of the message is scheduled for 
transmission, the "last block" flag is set. When the pacing 
engine encounters a "last block" flag, and the length equals 
the max length, it causes a final cell including the calculated 
CRC to be inserted (if configured to do so) in the CRC field 
of the last cell. 

As previously mentioned, the "next time" field of each 
context can be used to allow the processor 12 to render each 
context active or inactive. Contexts can be rendered active 
by setting the valid bit in the next time field. If all contexts 
have next time values which are not valid, or later than the 
current time, only idle cells will be transmitted (if this 
function is enabled). 

By varying the time intervals associated with the different 
contexts, different bandwidths can be allocated to the cor- 
responding message channels. Pacing can therefore be 
implemented on a per-message-channel basis by setting the 
times and intervals of the message channels as desired. 

In some circumstances it may be necessary to have direct 
control over the time at which cells are to be transmitted. To 
achieve this the processor 12 can disable normal selection of 
message channels by the pacing engine and can instead 
insert messages itself for transmission, which results in the 
message being sent immediately. 

The outgoing context contains two fields used in the 
pacing operation: NextTime and Interval. The NextTime 
field indicates the time at or after which a cell from that 
context is due to be sent. The Interval field indicates the 
intended interval between the transmission of successive 
cells from the data stream corresponding to the context. In 
normal operation, at each tick of the pacing clock the pacing 
engine checks the NextTime fields of the contexts, sends a 
cell from the context with the earliest value in the NextTime 
field and then increments that NextTime field by the stored 
Interval for that context. 
Register Map 

The details of the register map of the system will now be 
described. The following registers are available: 

The Content Addressable Memory appears to the main 
processor 12 as a peripheral located in the memory map 
of the processor. The CAM is 32 entries deep, each 
entry consists of four words. However not all the bits 
in the word are used in each entry. The structure of the 
CAM is illustrated in FIG. 14. Each entry in the CAM 
comprises four words. One word holds the match value 
that is to be compared with the VCI/VPI data from cell 
headers. One bit of the next word indicates whether the 
entry is valid for current use. The other two words hold 
the mask data for the entry. All locations in the CAM 
should preferably be initialised by the processor before 
enabling the reassembly engine. The size of the CAM 
is the limiting factor for the number of channels that 
can be handled directly in hardware. However, the size 
of the CAM is not limited to 32 entries or 4 words and 
could be larger or smaller. 

Header Match register contains the ATM cell header being 
matched against the CAM. This can be used to access 
the header information for the current cell being pro- 
cessed. 

Valid Match register contains the upper 32 bits (valid bit) 
for a CAM entry whose header matches. This can also 
be used to access the header information for the current 
cell being processed. 

Match Line register contains the results of the match 
between the incoming header and the contents of the 
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CAM. Each bit corresponds to a single match line in the 
CAM, bit 0 to Cam entry 0, bit 1 to entry 1 etc. 

Segmentation Control register is a 32 bit register which 
can be read from or written to. It contains four func- 
tional fields: 



Functional Field Function 

StartSegmentation When set informs the 

segmentation engine to start. 
If de-asserted whilst the 
segmentation is operating the 
current transfer will be completed 
before the segmentation engine 
is disabled. 

EnablePacingEngine Enables the pacing engine 
EnablePacingClock Enables the pacing clock 

IdleCellGeneration Send idle cell when no valid 

context is ready to be sent 



ReassemblyControl register is a 32 bit register which can 
be read from or written to. It also contains four func- 
25 tional fields: 



Bit Field Function 

30 StartReassembly Informs the reassembly engine to 

start 

EnableldleCellRemoval Enable transparent removal of idle 
cells 

ErrantCellControl Define the behaviour of the 

reassembly engine on detecting a 
35 cell which has no match in the 

CAM 



The ErrantCellControl field has four states: 
40 Delete all errant cells 

Move the complete cell including the four bytes of 
header to the context referenced by the Reassembly 
ErrantCellStartAddress. This allows the CPU to 
45 group unrecognised cells before processing them 

reducing the overhead required to process large 
number of unrecognised cells 
Copy the four bytes of the header to the buffer pointed 
to by ReassemblyErrantCellStartAddress and set 
50 NoMatchlnCam bit. The cell is not deleted in this 

mode but held in the fifo. It will be re-presented to 
the CAM on clearing the interrupt. 
Transfer cell including the four bytes of header to 
55 ReassemblyErrantCellStartAddress and set 

NoMatchinCam bit. The cell is moved to memory 
and removed from a FIFO buffer in the transfer path, 
therefore the next cell to be processed will be a new 
cell. 

60 

Segmentation Context Start Address is the address to use 
as the pointer to the start of the segmentation contexts 

Reassembly Context Start Address is the address to use as 
the pointer to the start of the reassembly contexts 

65 

Interrupt Enable register allows control over the interrupt 
functions and has the following fields: 
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Bit Field 



Function 



Bit Field 



Function 



OnNoMatchlnCam 

OnSingleMatchlnCam 

OnMultipleMatches InCam 
OnCellAvailable 

OnCelLCorrupt 
OnCcllError 

OnSarPduBuffcrOverFlow 
OnPduComplete 
OnReass emb lyCrcError 
OnRcasscmblyPduError 
OnRcadyTbScndCcll 

OnPduBufferExhausted 

OnSegmentationCompleted 

OnSegmentationError 



Raise an interrupt when header fails to 
match a CAM entry in order to re-p resent 
to the CAM on clearing of the interrupt. 
If clear then process cell as erroneous or idle 
Raise an interrupt when a cell header 
matches a single CAM entry. If clear 
then use CAM to generate context and 
process cell 

Raise an interrupt when more than one 
CAM entry matches header 
Raise an interrupt when a cell is 
available. If clear process cell as 
indicated by CAM 

Raise an interrupt when a corrupt cell 
has been received from the physical 
(UTOPIA) layer. If clear then delete 
cell without interrupt. 
Raise an interrupt when an error condition 
has occurred whilst transferring this cell, 
Reassembly controls the operation ad 
behaviour. If clear then transfer cell without 
interrupt. 

Raise an interrupt when PDU buffer is 
full and unable to accept current cell. 
Raise an interrupt when a complete PDU has 
arrived. 

Raise an interrupt when a reassembly CRC 
check failed. 

Raise an interrupt when a PDU related error 

condition has occurred 

Raise an interrupt if pacing engine indicates 

ATM stream is ready to accept cell. 

If clear the continue normal operation 

Raise an interrupt when a segmentation 

buffer has been consumed 

Raise an interrupt when the final PDU cell 

has been sent 

Raise an interrupt when an error occurs 
during segmentation. 



5 TransferlnProgress This is set when the cell 

transfer is in progress. It is 
clear when reassembly engine is idle 
CurrcntReassemblyContextAddress Address of context that is being 
used by the reassembly engine 
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Current Segmentation Context register contains informa- 
tion concerning the channel currently being segmented 
and has fields as follows: 



Bit Field 



Function 



TransferlnProgress 



20 



25 



30 



35 



CurrentSegmentationContextAddress 



This is set when the cell transfer 
is in progress. It is clear when 
segmentation engine is idle 
Address of context that is 
currently being used by 
the segmentation engine 



Interrupt Status register reflects the state of the interrupts 
and, if enabled in the InterruptRegisterEnable, allows 
the processor to determine the cause of an interrupt. 
The processor then writes back to the register to clear 
the interrupt. The areas are as follows: 
NoMatchlnCam 
SingleMatchlnCam 
MultipleMatchesInCam 
CellAvailable 
CellCorrupt 
CellError 

SarPduBufferOverFlow 

PduComplete 

ReassemblyCrcError 

ReassemblyPduError 

ReadyToSendCell 

PduBufferExhausted 

SegmentationCompleted 

SegmentationError 

Reassembly Errant Cell Start Address register contains 
the pointer to the location in which an errant cell or 
uomatched cell is stored for further use by the 
processor, if required. This register can also be used to 
point to a context used by the processor for handling 
cell streams itself. 

Current Reassembly Context register contains informa- 
tion concerning the channel currently being reas- 
sembled and has fields as follows: 



45 



50 



55 



Current Segmentation Time is the current absolute time 
used by the SAR engine. 

Number of Outgoing Contexts register is the number of 
outgoing contexts to be used by the segmentation 
engine, which is set to a default of 32 in this 
embodiment, but can be programmed to be other values 
as required. 

Next Segmentation Context Address register is used when 
a transfer is to be made by the engine and the pacing 
engine is disabled. The register CurrentSegmentation- 
ContextAddress is set by the CPU to point to the 
address of the context from which a cell is to be 
transmitted. The bit TransferlnProgress, is set to enable 
the transfer by the processor. When the transfer is in 
progress the TransferlnProgress bit is set. When the 
transfer is complete the TransferlnProgress bit is unset. 

Pacing Clock Control register allows control of the pacing 
clock. PacingClockPeriod defines the period of the 
pacing clock as a multiple of the system clock period. 
This implicitly defines the resolution of the pacing 
function and the time contained within the context. 
Pacinglnterval is the number of pacing clock periods 
which need to occur before the pacing function exam- 
ines the context to determine if another cell should be 
sent. The available fields are as follows: 



Bit Field 


Function 


PacingClockPeriod 


Sets the period of the pacing clock 




as a multiple of system clock cycles 


Pacinglnterval 


Sets the pacing interval period as a 




multiple of the pacing clock 



Contexts 

Each set of contexts is located in a contiguous area of 
60 memory. The memory may be in internal memory, external 
memory or indeed the shared memory. The SAR is told the 
base of each block of contexts by writing to the appropriate 
ContextStartAddressregister (described in the previous 
section). This section describes the layout of the contexts 
65 and gives the meanings to any attributes within the contexts. 
Each incoming context (used for reassembly) looks as 
follows: 
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-continued 



Field 



Function 



Field 



Function 



CRC 



Flags 



BufferPointer 

MaximumAndCurren tLcngth 



Running CRC value used by the 
Reassembly engine 
Rags used to direct behaviour 
and report status 

Pointer to the next free buffer area. 
Current length and maximum 
length word 



The MaximumAndCurrentLength field is structured as 
follows: 



Flags 

NewTime 
Interval 



10 VO/VPI 
BufferPointer 

MaximumAndCurrentLength 



Flags used to direct the behaviour and 
report status 

The next absolute time to output a cell 
Time interval to add to NewTime after 
a cell using this context has been 
transmitted 

Header prepended to each cell prior to 
transmission 

Pointer to the buffer containing the PDU 
Current length and maximum length word 



15 The MaximumAndCurrentLength field is structured as 
follows: 



Bit Field 


Function 








MaximumLength 
CurrcntLength 


Amount of buffer space in total 
pointed to by BufferPointer 
Amount of data that has been currently 
transferred to the buffer area 
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Bit Field 


Function 




MaximumLength 


Size of (partial) PDU in current buffer 
pointed to by BufferPointer 



The CRC field contains either a 10-bit CRC for data 
streams such as OAM, RM, AAL3/4 or a 32-bit CRC for 
AAL5 streams, as defined by the ATM Forum and other 
standards. These two modes of error checking require dif- 
ferent initial and final values to be set, the final value being 
that expected if the CRC check has succeeded. If the CRC 
is not enabled for this context, the contents of this field are 
not defined, updated or used by the engine. 

The Buffer Pointer points to the next word in memory that 
the reassembly engine will access when transferring an ATM 
stream. It may point to any location in memory. 

The flags used are as follows: 



Bit Field 



Function 



IgnorePayload 
Enab leCrcCheck 
CRC32CRC10 
PTIEqualsLength 



LimitedUpdate 
DisablePduEvents 



ContextValid * 

ContextFull * 
ContextComplete ' 

ContextCrcError * 
ContextError * 



PHYAddress 



Ignore the payload 
Enable CRC checking 

If set use a 32 bit CRC otherwise use a 10 bit 

If set the PIT in the ATM header will indicate 

the end of PDU else Maximum- Length 

indicates size of PDU. 

If set then update only Flags field. 

If set then do not raise interrupts for 

PduComplete, PduBuffer-Overflow 

or RcassemblyPduError. 

If set then the context was valid when a 

cell was last transferred. 

If set then the buffer has been filled. 

If set then the transfer of the PDU to 

the buffer has completed. 

If set then a CRC check has failed for this context 
If set then an error has occurred in this buffer. 
This means CurrentLength is greater than 
MaximumLength. 

Address of the PHY device from which the 
last cell was transferred 
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• Status bits maintained by engine 

Each outgoing context (used for segmentation) is as 
follows: 



Field 



Function 



CRC 



Running CRC value used by 
the Segmentation engine 



65 



CurrentLength 



Amount of data that has been transmitted 



25 The segmentation CRC field used for outgoing contexts is 
in a similar format to that of the reassembly CRC, containing 
either a 10-bit CRC for streams such as OAM, RM, ML3/4 
or a 32-bit CRC for AAL5 streams, as defined by the ATM 
Forum and other standards. These two modes of error 

30 checking require different initial and final values to be set, 
the final value being that expected if the CRC check has 
succeeded. If the CRC is not enabled for this context, the 
contents of this field are not defined. 

The Buffer Pointer points to the next word in memory that 

35 the segmentation engine will access when transferring an 
ATM stream. It may point to any location in memory. 
The flags used for segmentation are as follows: 



Bit Field 


Function 


LastBlock 


The PDU pointed to by Buffer-Pointer is 




the final one 


EnableCrc 


Insert a CRC in the Final cell 


CRC32CRC10 


If set then perform a 32 bit CRC else a 10 bit CRC 


InsertPTI 


Updates PTI in the cell header for final cell 


LimitedUpdate 


If set then the segmentation engine will 




only update the Flags and NewTime fields 




in this context 


DisablePduEvents 


If set then do not raise interrupts for 




SegmentationCompleted 




PduBufferExhausted or 




SegmentationErro r. 


PHYAddress 


Address of the PHY device to which 




the last cell was transferred 


PduValid * 


The context associated with PDU is valid 


BufferExhausted * 


The PDU in the buffer has been consumed and 




more is expected 


PduComplete " 


The segmentation of the PDU pointed to 




by BufferPointer has been completed 


Error * 


An error has occurred using this context 




This means CurrentLength is greater 




than MaximumLength 



* Status bits maintained by engine 

Overview 

An important advantage of the SAR engine is that the 
implementation of some functions in hardware and other 
functions in software allows a device to be made with a 
relatively small die area and relatively high performance. It 
is preferred that the following functions are performed in 
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hardware: checksum calculation, identification of ATM 
headers (suitably by means of a CAM for reassembly), DMA 
functions to and from memory, pacing of upstream ATM cell 
transmission on a per-VC basis, and handling of interrupts 
and control interfaces to an on-chip CPU core. It is preferred 5 
that the following functions are performed in software by 
means of the on-chip CPU core: memory management and 
buffering strategy for ATM cells, AAL5 Protocol Data Units 
(PDU), MPEG transport streams and other data i.e. memory 
management for a variety of messages; and RM cell pro- 10 
cessing and other functions in support of ABR modes of 
operation 

The apparatus as described above is especially suitable for 
implementation by an embedded microprocessor with 
appropriate software or firmware. This means that the data is 
structure can be made completely generic — for example, 
buffers with a length of a single cell can be allocated, so as 
to reduce fragmentation of memory. Software running of the 
microprocessor can implement any desired management 
scheme. 20 

The applicant draws attention to the fact that the present 
invention may include any feature or combination of fea- 
tures disclosed herein either implicitly or explicitly or any 
generalisation thereof, without limitation to the scope of any 
of the present claims. In view of the foregoing description it 25 
will be evident to a person skilled in the art that various 
modifications may be made within the scope of the inven- 
tion. 

What is claimed is: 

1. Apparatus for re-assembling information cells, each 30 
respective information cell comprising a respective part of 
one of a plurality of messages and cell content information 
indicating an identity of the one of the plurality of messages 
the respective part of which is earned by the respective 
information cell, comprising: 35 
a message memory for respectively storing the plurality of 
messages, each in one or more blocks, the one or more 
blocks for storing each respective message of the 
plurality of messages being capable of being of differ- 
ent lengths; 4 ° 
a message data memory for storing, for each respective 
message, message data defining a location in the mes- 
sage memory, a position in the one or more blocks and 
a length of one of the one or more blocks that is to 
receive the information cells of the respective message; 
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a location memory for storing, for each respective 
message, an indication of the location of the message 
data stored for the respective message in the message 
data memory; 

loading apparatus for receiving the information cells, and 
for each respective information cell, accessing the 
location memory to determine the location of the 
message data for the respective message the respective 
part of which is carried by the respective information 
cell, storing the respective information cell in the 
message memory at the location indicated in the mes- 
sage data, incrementing the message data defining the 
location and the position in the one or more blocks in 
the message data memory by an amount equal to a 
length of the respective part of the respective message 
carried by the respective information cell and compar- 
ing the incremented position with the stored length of 
the one block for the respective message to determine 
whether the end of the one block has been reached. 

2. Apparatus as claimed in claim 1, wherein as each 
respective part of the respective message is received, the 
loading apparatus performs an error check calculation on the 
respective part and stores the result of the error check 
calculation in the message data memory. 

3. Apparatus as claimed in claim 2, wherein upon 
receiving, in the respective information cell, error check 
information for the respective message, the loading appara- 
tus compares the error check information with the stored 
result of the error check calculation. 

4. Apparatus as claimed in claim 1, wherein the location 
memory is a content addressable memory. 

5. Apparatus as claimed in claim 1, provided on a single 
integrated circuit. 

6. Apparatus as claimed in claim 5, wherein the integrated 
circuit comprises a Central Processing Unit. 

7. Apparatus as claimed in claim 5, wherein at least part 
of the message data memory is provided separately from the 
integrated circuit. 

8. Apparatus as claimed in claim 1, wherein the length of 
the respective part of the one of the plurality of messages 
carried in each information cell is 384 bits. 

9. Apparatus as claimed in claim 1, wherein the informa- 
tion cells are .AIM cells. 
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